Unlike the Mailbox server role and to some extent the Transport server roles, the Client
Access Server role does not have any inherent high-availability
functionality built in. That does not mean that it was designed without
high availability in mind—it just requires other modalities to provide
high availability. A separate product or feature is required to provide
this functionality. The following sections cover choosing and configuring the best solution depending on deployment requirements.
1. Client Access Load Balancing and Failover Solutions
To provide Client Access high availability requires multiple Client
Access servers to be deployed in the same Active Directory site. As
mentioned, there is no integrated mechanism to provide load balancing
and failover capabilities if a host becomes unavailable or overloaded.
However, a variety of products are available that fill this need.
Because the Client Access servers provide so many services with a
number of different connections types—from OWA to MAPI to Web
Services—three types of Client Access server traffic actually need to
be load balanced:
Traffic from internal networks
Traffic from external (Internet) networks
Traffic from other Client Access Servers (proxy)
1.1. Affinity
Some Exchange communications are stateful,
meaning the application requires that the communication context be
maintained with the same host until the session is completed. This is
common in conversations that we have daily. If a co-worker asks what
the deadline is for your project and then you walk into another
co-worker's office and say "Wednesday," she will likely have no idea
that you were answering John's question. This is similar to how a stateful
program works: It expects to continue communication with the same
context until the conversation is completed. Other protocols are
stateless, such as HTTP, where state information is lost between client
requests. In the case of multiple, load-balanced hosts, affinity is a mechanism to direct subsequent calls to the host that answered the initial request.
It is important to understand the different types of affinity and how they are used. The Client Access server uses a number of protocols that will need to be load balanced, including HTTP and RPC. Remember some Client Access server protocols require affinity and some do not.
1.1.1. Existing Cookies
Existing cookie affinity
uses cookie information transmitted during typical client/server
sessions. This type of affinity is only useful for protocols using HTTP
and thus not an option for any RPC communication. OWA using forms-based
authentication is an example of an application that does use existing
or application cookies.
1.1.2. Load Balancer Cookies
Using load balancer cookies
is similar to using existing cookies except that the load balancer
creates the cookie and does not rely on any existing cookies. As with
existing cookies, this is only usable with HTTP. Additionally, the
client must support the addition of the load balancer–generated cookie.
Exchange ActiveSync, Outlook Anywhere, and some Exchange Web Services
do not support this capability. However, Outlook Web App, Exchange
Control Panel, and Remote Windows PowerShell are good candidates for
this type of affinity.
1.1.3. Source IP
Source
IP is perhaps the most common and widely supported type of affinity.
With Source IP affinity, the load balancer records a client's IP
address and the initial destination host. All subsequent traffic from
that source IP will continue to go to the same destination host for a
period of time. However, source IP load balancing has two main
drawbacks.
First, affinity breaks when
clients change their IP addresses. If you have an environment where
this happens frequently, such as mobile clients roaming between wireless networks, this will cause issues. Users may experience symptoms such as having to re-authenticate.
Second, if you have an environment where many clients share the same source IP, such as when a device performing Network
Address Translation (NAT) is used, the load will not be evenly
distributed because all clients behind the NAT will be routed to the
same destination IP address.
1.1.4. SSL Session ID
SSL session ID is generated when establishing an SSL encrypted session. The SSL
session ID has a big advantage over source IP affinity: It can uniquely
identify clients sharing the same source IP address. Another advantage
is that there is no requirement to decrypt the SSL traffic. This is a
hard requirement for using client CA because renegotiating the SSL
session ID puts additional overhead on the server. Directing traffic to
the same server saves processing time and prevents performance impacts.
SSL
session ID does not work well with all clients. Some browsers and
mobile devices, such as Microsoft Internet Explorer 8.0, create a new
SSL session for each browser process. Therefore, every time a user
creates a new e-mail message, a separate window opens, which creates a
new SSL session. The exception to this is when users use client CA. The
same SSL session ID is used for all communication to a specific host.
Outlook Anywhere and some mobile clients also open several Client Access Server sessions. Each session receives a different SSL
session ID, so each session could end up being connected to a different
server. As discussed earlier, this is not a problem because Windows Server 2008 network load
balancing can correlate the RPC_IN_DATA and RPC_OUT_DATA; however, it
does cause additional overhead and can negatively impact server
performance.